Configurable document server

ABSTRACT

A configurable document server is described. In some embodiments, the configurable document server can enable administrators to set an option that prevents documents from being routed to users when the configurable document server experiences some types of errors. When the configurable document server determines that such an error condition exists, it may prevent the routing of the corresponding document. By preventing documents causing errors from being routed, the configurable document server enables administrators to improve the accuracy of document workflow and thereby improve productivity of users.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application claims the benefit of U.S. Provisional PatentApplication Ser. No. 60/835,228, filed Aug. 2, 2006, entitled “RighffaxImprovements” which is incorporated herein in its entirety by reference.This patent application also incorporates by reference commonly assignedU.S. patent application Ser. No. 11/591,449, filed on Oct. 31, 2006,entitled “Queue Processor for Document Servers,” and U.S. Pat. No.6,747,761, filed on Oct. 29, 1996, entitled “Delivery Expert System andMethod.”

BACKGROUND

Computer networks generally enable data communications between computingdevices (“network nodes”) that are connected to such computer networks.Many such computer networks are interconnected, such as via theInternet, and can have “transports” that transport documents and othercomputer files between network nodes. A document is a container for anytype of digital content, including facsimiles, voice messages, videos,word processing documents, spreadsheets, and any other type of media,including multimedia.

Conventional transports have various deficiencies. As an example,conventional transports cannot intelligently select a network frommultiple available networks based on the type of document that needs tobe communicated between computing devices. Instead, they generally usethe same network to transport documents without regard as to whethersome networks may be better adapted to transport a particular documenttype. Moreover, document servers may not route documents even thoughdocuments may not be correctly converted, received, or transmitted.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating a suitable computing system inwhich aspects of the invention may be implemented.

FIG. 2 is a flow diagram illustrating a send_document routine invoked bya Document Transport module in some embodiments.

FIG. 3 is a block diagram illustrating use of the Document Transport insome embodiments.

FIG. 4 is a block diagram illustrating a Document Transport with MIMEsupport.

FIG. 5 is a block diagram illustrating rules for least-cost-routing andfor store-and-forward document transport in some embodiments.

FIG. 6 is a block diagram illustrating some of the queue management doneby separate protocols administered by Document Transport.

FIG. 7 is a block diagram illustrating an environment in which aconfigurable queue processor may operate in some embodiments.

FIG. 8 is a block diagram illustrating operation of a configurable queueprocessor in some embodiments.

FIG. 9 is a flow diagram illustrating a process_document routine invokedby a document flow in some embodiments.

FIG. 10 is a flow diagram illustrating an allocate_document_flow routineinvoked by a configurable queue processor in some embodiments.

FIG. 11 is a flow diagram illustrating a prevent_routing routine invokedby the configurable document server in some embodiments.

The headings provided herein do not necessarily limit the scope of theinvention.

DETAILED DESCRIPTION

Various embodiments of the invention will now be described. Thefollowing description provides specific details for a thoroughunderstanding and enabling description of these embodiments. One skilledin the art will understand, however, that the invention may be practicedwithout many of these details. Additionally, some well-known structuresor functions may not be shown or described in detail, so as to avoidunnecessarily obscuring the relevant description of the variousembodiments

The terminology used in the description presented below is intended tobe interpreted in its broadest reasonable manner, even though it isbeing used in conjunction with a detailed description of specificembodiments of the invention. Some terms may even be emphasized below.However, any terminology intended to be interpreted in any restrictedmanner will be overtly and specifically defined as such in this DetailedDescription section.

A configurable document server is described. In some embodiments, theconfigurable document server can enable administrators to set an optionthat prevents documents from being routed to users when the configurabledocument server experiences some types of errors. As an example, anadministrator can configure the document server to prevent routing ofinbound facsimile messages when those facsimile messages are incompletebecause of transmission or reception errors. The configurable documentserver may determine that an error has occurred when the inboundfacsimile was not completely transmitted, when the power fails, when theconnection terminates, or other error conditions occur. Alternatively,the configurable document server may determine that documents that couldnot be converted from one document format to another because of an errorshould not be routed. When the configurable document server determinesthat such an error condition exists, it may prevent the routing of thecorresponding document. As an example, the configurable document servermay instead route the document to an administrator or identify thedocument to the administrator. By preventing documents causing errors,such as facsimile documents with transmission errors, from being routed,the configurable document server enables administrators to improve theaccuracy of document workflow and thereby improve productivity of users.

A configurable queue processor for document servers is described. Insome embodiments, the configurable queue processor allocates serverresources in an optimal manner such that document servers can processdocuments efficiently. Server resources include, e.g., processors, diskspace, network bandwidth, etc. A document server is a server thathandles documents or otherwise processes documents, such as servers thatprocess facsimiles, copies, print jobs, scanning jobs, optical characterrecognition jobs, voice messages, document transmissions, documentconversions, archiving, and indeed any type of document processingrequest. Document servers may receive multiple documents of varioustypes. The configurable queue processor allocates one or more “documentflows” to handle the incoming documents. A document flow is a componentof a document server that manages the processing of one or moredocuments or document types. As an example, the configurable queueprocessor may allocate multiple document flows and configure eachdocument flow to handle different types of documents. The document flowsreceive documents they are configured to handle from a queue and handlethe documents according to each document's type. The document flows canprovide the received documents to appropriate document handlers, such asfor sending a facsimile, making a copy, printing, optical characterrecognition, etc.

In various embodiments, the document flows can retrieve documents from aqueue or may be provided documents by another component, such as theconfigurable queue processor.

The configurable queue processor can be configured by a user, such as anadministrator, to allocate document flows in an identified manner. As anexample, an administrator may determine that facsimile transmissions areto receive higher priority during the day than another type of documentprocessing service the document server provides, but can receive a lowerpriority at night. Alternatively, the configurable queue processor canallocate document flows dynamically to balance system load. As anexample, the configurable queue processor may allocate an identifiednumber of document flows and, as server resources become available orare consumed, can increase or decrease the number of document flows.Alternatively, the configurable queue processor may increase or decreasethe number of document flows as the queue of documents waiting to beprocessed increases or decreases. As an example, the configurable queueprocessor may increase the number of document flows that handlefacsimiles as the number of waiting facsimiles in the queue increases.

In some embodiments, the configurable queue processor may increase thenumber of queues that hold pending documents.

In various embodiments, the configurable queue processor may allocatedocument flows across one or more document servers. Alternatively, eachdocument server may have its own configurable queue processor thatallocates document flows on that document server.

Thus, by using multiple document flows, the configurable queue processorcan tune system performance to manage a document's time in the queue,such as by managing system performance or resources. This permitsflexible management of queues in document servers, such as to preventbottlenecks associated with the processing of multiple document types,events, and network protocols.

Various techniques can be employed to enable communication between theconfigurable queue processor and allocated document flows. These includeshared memory, named pipes, remote procedure calls, applicationprogramming interface invocations, etc.

The document flows that the configurable queue processors createcommunicate with universal Document Transport (“DocTrans”) modules toprocess documents or forward documents for processing. The DocTransmodules may be adapted for use with document servers for recognizingdocument requests, interacting with routing rules and workflowrequirements, and generally managing document flows between networknodes, including other document servers. The DocTrans module canfunction with a document server (e.g., a RightFax server) to recognizedocument requests, interact with document routing rules and workflowrequirements, and manage document flows between network nodes ordevices. The DocTrans module provides to its operator multiple benefitsover conventional transports. Examples include providing a commonprocessing architecture for all message transports rather than requiringindividual processing engines for multiple transport types; havingcommon scheduling and queuing support for each transport type; andselecting document- or hardware-specific processing tasks by referenceto the type of protocol. This feature is prevalent now given the wideuse of multifunction devices such as all-in-oneprint/scan/copy/fax/telephone/answering machine devices, which may beenhanced with audio & video capture, messaging, email, network router &gateway capabilities. It is also a benefit to use DocTrans modules tointegrate messaging and workflow operations when using standalonemachines that perform these functions on a network.

Various techniques can be employed to enable communication between theconfigurable document flows and their corresponding DocTrans modules.These include shared memory, named pipes, remote procedure calls,application programming interface invocations, etc.

The DocTrans module provides methods for transporting documents betweennetwork devices, such as printers, fax boards, and document servers(e.g., RightFax 9.0 facsimile server by Captaris, Inc. of Bellevue,Wash.) across local and wide-area networks, and permits documenttransport and routing optimization with other types of communicationsnetworks (e.g., messaging services, telephony, and Internet Protocol(“IP”) networks). Document servers can handle faxes and other documents,such as for routing purposes. The module can route documents instead of,or in addition to, a board server, such as a fax board server. TheDocTrans module routes documents in a manner that is similar to how aboard server routes documents, except that the DocTrans module can routedocuments based on a document type or a transport's type in addition tojust phone number, user, group, and so forth. In addition, the DocTransmodule exposes an interface that permits other types of documenttransport mechanisms (e.g., multi-function devices, email, and SMSservers) to operate with various networks systems, and to be extended sothat routing operations (such operations as StartTransmission,SendDocument, ReceiveDocument, EndTransmission, or StatusCheck) can bereadily used with other network services.

The DocTrans module can be implemented as an independently configurablesoftware module that transports content and related metadata acrosscomputer networks. It can function as a communication layer betweenvarious computer networks and network servers that perform discretedocument creation, storage and transmission tasks. The DocTrans modulecan operate independently of the originating message service or sourceof a document to perform operations on documents, such as send, receive,or cache documents and messages, once a task is loaded, and can operateindependently to receive items (such as facsimile tasks) for forwardinglater. It permits flexible, programmable, and optimized rules-basedrouting of documents in various message formats and on multiple networktypes.

Conventional fax products did not provide board servers with loadingbalancing capabilities or analysis of cost, time, or security rules forrouting across multiple types of document and messaging protocols (e.g.,MIME, SMS, T.37 fax, T.38 fax). By contrast, the DocTrans module isextensible to perform document transport and load equalization onvirtually all document types and network types using those messagingprotocols. This feature is prevalent now given the wide use ofmultifunction devices such as all-in-oneprint/scan/copy/fax/telephone/answering machine devices, which may beenhanced with audio & video capture, messaging, email, network router &gateway capabilities. It is also a benefit to use DocTrans modules tointegrate messaging and workflow operations when using standalonemachines that perform these functions on a network.

Turning now to the figures, FIG. 1 and the following discussion providea brief, general description of a suitable computing environment inwhich aspects of the invention can be implemented. Although notrequired, aspects and embodiments of the invention will be described inthe general context of computer-executable instructions, such asroutines executed by a general-purpose computer, e.g., a server orpersonal computer. Those skilled in the relevant art will appreciatethat the invention can be practiced with other computer systemconfigurations, including Internet appliances, hand-held devices,wearable computers, cellular or mobile phones, multi-processor systems,microprocessor-based or programmable consumer electronics, set-topboxes, network PCs, mini-computers, wireless network devices, mainframecomputers and the like. The invention can be embodied in a specialpurpose computer or data processor that is specifically programmed,configured or constructed to perform one or more of thecomputer-executable instructions explained in detail below. Indeed, theterm “computer”, as used generally herein, refers to any of the abovedevices, as well as any data processor.

The invention can also be practiced in distributed computingenvironments, where tasks or modules are performed by remote processingdevices, which are linked through a communications network, such as aLocal Area Network (“LAN”), Wide Area Network (“WAN”) or the Internet.In a distributed computing environment, program modules or sub-routinesmay be located in both local and remote memory storage devices. Aspectsof the invention described below may be stored or distributed oncomputer-readable media, including magnetic and optically readable andremovable computer discs, stored as firmware in chips (e.g., EEPROMchips), as well as distributed electronically over the Internet or overother networks (including wireless networks). Those skilled in therelevant art will recognize that portions of the invention may reside ona server computer, while corresponding portions reside on a clientcomputer. Data structures and transmission of data particular to aspectsof the invention are also encompassed within the scope of the invention.

Referring to FIG. 1, one embodiment of the invention employs a computer100, such as a personal computer or workstation, having one or moreprocessors 101 coupled to one or more user input devices 102 and datastorage devices 104. The computer is also coupled to at least one outputdevice such as a display device 106 and one or more optional additionaloutput devices 108 (e.g., printer, plotter, speakers, tactile orolfactory output devices, etc.). The computer may be coupled to externalcomputers, such as via an optional network connection 110, a wirelesstransceiver 112, or both.

The input devices 102 may include a keyboard and/or a pointing devicesuch as a mouse. Other input devices are possible such as a microphone,joystick, pen, game pad, scanner, digital camera, video camera, and thelike. The data storage devices 104 may include any type ofcomputer-readable media that can store data accessible by the computer100, such as magnetic hard and floppy disk drives, optical disk drives,magnetic cassettes, tape drives, flash memory cards, digital video disks(DVDs), Bernoulli cartridges, RAMs, ROMs, smart cards, etc. Indeed, anymedium for storing or transmitting computer-readable instructions anddata may be employed, including a connection port to or node on anetwork such as a local area network (LAN), wide area network (WAN) orthe Internet (not shown in FIG. 1).

FIG. 2 is a flow diagram illustrating a send-document routine performedby the DocTrans module in some embodiments. The routine may be employedby the facility to send a document, such as a fax document. The routinebegins at block 202 where it receives an indication of a document as aparameter.

At block 204, the routine applies dialing or routing rules to theindicated document. The dialing or routing rules determine how thefacility is to transport or route a document. As an example, dialing orrouting rules may indicate that a document that is to be sent at aspecific time or is from a particular user is to be sent using aspecific document transport.

At block 206, the routine selects a target based on the applied dialingor routing rules. As examples, the routine may select a public servicetelephone network (“PSTN”), another RightFax server, a board servercontaining one or more communications devices, and so forth. Asexamples, the DocTrans may select a target based on metadata, type ofdocument, or other attributes relating to the document.

At block 208, the routine routes the document to the selected target.The selected target may perform additional analyses on the document androute the document to another DocTrans so that the document can berouted appropriately.

At block 210, the routine returns.

FIG. 3 is a block diagram illustrating use of the DocTrans in someembodiments. According to the illustrated embodiment, a document 302enters a RightFax server 304, such as after the document is scanned. Aworkflow application 310 may take various workflow steps, such as whenthe document is scanned, received, sent, etc. This document is routed toa DocTrans module 306. This DocTrans could reside in the same computingdevice as the RightFax server or in a different computing device, inwhich case it is referred to as a “Remote DocTrans.” The DocTrans mayinvoke the “send-document” routine described above in relation to FIG. 2to route the document to another DocTrans module. Once the document hasbeen transferred to one of the DocTrans modules, dialing or routingrules 308 may be applied to this document. Dialing or routing rules canbe applied based on information pertaining to the document, such asphone number, DocTrans, group, users, etc. A dialing rule may cause thedocument to be routed to another DocTrans, or to a specific type oftransport. Transports include, e.g., fax boards (e.g., from Brooktrout,Eicon, Intel, etc.), SMS devices, routers (e.g., from Cisco) for T.38fax, email, T.37 (Store and Forward) fax, a DocPlus (e.g., Xpedite)provider, virtual implementation of the above, including documenttransmission simulations (e.g., evaluating cost, schedule, destination,and security for transmission), and so forth.

Extensibility and Routing Priorities

Since the DocTrans operates independently of network connections,content servers, or network resources providing the document, it canreadily be configured to handle multiple document types and routedocuments to multiple types of network connections. As an example, theaddition of email MIME types provides a secure and reliable transportfor email from any point on the network. Moreover, the facility canconfirm deliverability of the email, verify or certify receipt ofcontents and attachments; confirm results of operations performed by theDocTrans in routing the document to various network nodes for storage,transmission, and notifications; and so forth. By using rules thatemploy a TCP/IP transport between RightFax servers with encryption andsecure session protocols (e.g., contrasted with open transmission ontelephone lines), the DocTrans can provide secure routing of documents,such as facsimile (“fax”) documents. To secure email messages andattachments, the fax server could provide certified delivery fordocuments or messages encrypted by the source server. As an example, thefax server could employ independent sender and recipient verificationsand notifications for certified delivery.

FIG. 4 illustrates a DocTrans with MIME support, such as for using emailwith a DocTrans module in some embodiments. While the figure illustratesa MIME-type document, other document types are also possible. Flexiblerouting based on DocTrans permits simple mail transport protocol(“SMTP”) services for email operating with the RightFax server totransmit an email document 402 between DocTrans modules associated withRightFax servers directly, then into a client inbox (e.g., Microsoft®Outlook®) 408 on a RightFax client machine via an Intranet 406 and anemail server 404. The illustrated embodiment identifies severaladvantages over the prior art. Because there are redundant links betweenDocTrans modules, “failsafe” transmission becomes possible. As anexample, when one DocTrans node is unavailable, the facility can employanother DocTrans module to ensure that the document is delivered.Content services on a RightFax server can archive, search & retrieve,and store native documents, such as emails and their attachments. Thesystem can apply workflow by using, for example, Captaris' RightFax EDCAPI or Captaris' WorkFlow product, such as to accomplish multiple taskswith the same transmission (e.g., storing, logging, notifying, printing,and archiving). Metadata regarding the document, its routing to knownDocTrans modules, and the network and communication resources availablecan be stored and applied as well. For example, this information couldbe requested and bound to the fax server document or task log for eachtask for later retrieval.

Because the system has access to the intranet and Internet, it canverify and certify that emails and any related documents were deliveredor that web links contained therein can be accessed. The system candeliver documents via alternate transport mechanisms. For example, if anemail with MIME attachments could not be delivered, the system couldalternately route the email text as an SMS message and provide theattachments as file pathnames or URL links. Alternatively, the DocTranssystem can convert an SMS message into a facsimile, or a facsimile intoa Fax-Over-IP (FOIP) document, and send it using one of severalfacsimile transports (e.g., telephone line, or T.37/T.38 fax over IP,etc.). The DocTrans system can also confirm the origin, validity,delivery and source of the document as required by using an independent,secure notification and document validation method.

In this manner, the system enables receiving and employing extensionsfor connecting to various transports, configuring dialing and routingrules for these transports, and handling the routing of messageprotocols, such as for MIME, SMS, T37 Fax, T38 Fax, and RightFax server.The system also enables extensions for specific facsimile hardware, suchas Eicon and Brooktrout. Third party vendors that use RightFax (“RF”)server for their document transport can enhance their capabilities byusing DocTrans.

Least-Cost Routing

Least-cost routing rules enable transmission of facsimile documents overTCP/IP connections to other RightFax servers or to local multifunctionprinter devices, where the document may be printed, sent at localtelephone rates rather than long distance rates, or transmitted over anavailable TCP/IP connection. In particular, using server-to-server IPnetwork transmission of faxes enables managing the long-distance callingcosts of sending faxes on telephone networks. Moreover, the facility canthen employ local storage to replicate documents. The ability tostore-and-forward documents in local networks (e.g., in RightFax serversor client inboxes) with logging for verification of receipt andretention of copies, enables re-transmission to be accomplished locallyshould the printed document or original email attachment be lost orinadvertently deleted. FIG. 5 is a block diagram illustrating rules forleast-cost-routing and for store-and-forward document transport in someembodiments. According to the illustrated embodiment, rules forleast-cost-routing and for store-and-forward document transport on thenetwork can be applied by the queuing and routing system. The correctrouting for a document can be determined with reference to the documenttype, transport protocol, availability of communications channels,availability of and load on network resources, and so forth.

A document 502 with metadata (e.g., metadata that contains informationpertaining to a sender) enters a server queue 503 of a DocTrans. Afterrouting rules 504 are applied to the document (e.g., based on themetadata) the document is scheduled on one of DocTrans's queues 506.These queues allow the DocTrans to treat all document types in a similarfashion. As an example, all Transport Mechanisms (“transports”) 508 canimplement the same or a similar application program interface (API) tointeract with these queues and receive documents for transmission.DocTrans is also able to identify documents based on document type(e.g., SMS, email, or RightFax) or transmission type (e.g., fax boardtransmission, T.37 transmission, or T.38 transmission). The transportsact as plug-ins to the DocTrans (e.g., all have identical or similarinterfaces, such as for various operations including StartTransmission,SendDocument, ReceiveDocument, EndTransmission, etc.) and new librariessupporting these operations can extend transmission capabilities in theDocTrans to add a new protocol. Also, in some embodiments, a queue willbe serviced if a transport that services that type of queue has beenconfigured on the DocTrans. In some embodiments, the document may beenqueued when (510) a transport associated with a queue is available.

FIG. 6 illustrates aspects of queue management performed by protocolsadministered by DocTrans in some embodiments. The illustrated embodimentindicates how queue management can be separated from each transporttype. In some embodiments, each queue is managed by a DocTrans module.Multiple transport types can be plugged-in and can service acorresponding queue. The DocTrans module performs queue management,maintenance, and scheduling of sending/receiving documents. According tothe illustrated embodiment, a RightFax server 602 sends a request 604 toa DocTrans module 606. Based upon dialing or routing rules, the DocTransmodule determines whether to use a RightFax queue 608, SMS queue 610, orglobal queue 612. The RightFax queue 608 may be configured to transportdocuments between other RightFax servers. The SMS queue 610 may beconfigured to communicate with an SMS service provider. The global queue612 handles board-level communications, such as by checking transportsthat are configured for use with the system, to determine whether one ofthese transports can handle the request 604. If one of the configuredtransports can handle the request, the global queue routes the requestto that transport.

Upon receiving a document, the DocTrans module delivers the document 614to the RightFax Server. The DocTrans module may also send notificationsto the RightFax Server upon receipt of a document 616.

Load Balancing

Load balancing is a factor that DocTrans modules use to determinewhether a document is to be processed or forwarded to another DocTransmodule. All DocTrans modules can perform load equalization based on acomparison of its load with other DocTrans modules in the network. Rulesbased on such formulae may be applied using cost parameters,transmission times, schedule times, security or priority parameters, androuting and destination information. Similarly, a DocTrans module can beused in conjunction with a workflow application or simulation engine toestimate and to optimize such rules before or during their applicationto a document transmission task. As an example, DocTrans modules mayperform load balancing based on the following formula: (total of X pagesfrom Y Documents)/(number of send channels).

Another method varies the load calculation by channel and content type,such as by using the following formula:

(Waiting Pages Of This Type*Expected Transport Time Per Page Of ThisDocument Type)/Number # of Channels Sending This Document Type.

These formulae may be evaluated for each document type. For example, ifemail can be sent in 3 seconds and a fax can be sent 1 minute, there are60 one “page” emails queued, 50 one page faxes queued, and there are 2e-mail channels, and 24 fax channels, the e-mail load would be:

60*3/2=90

and the fax load would be:

50*60/24=125

Managing Network Connections

If a resource is unavailable, such as because of a server outage, it maynot be considered for load balancing for a period of time (e.g., 40minutes) to permit the resource to be restored or reconfigured. Thisapplies to DocTrans, PSTN, Board Servers, and RightFax servers. In somecases, the system may use the local DocTrans to PSTN connection totransmit documents, even if that is not the preferred configuration orleast-cost routing for the document, such as when other networkresources are unavailable.

Grouping Using DocTrans

Conventional facsimile transmission has costs associated relating toconnections, such as call initiation and duration. The process ofgrouping avoids contention for connection resources or accrual ofconnection initiation charges when multiple documents are directed tothe same destination. Grouping can prevent tasks from waiting on a“busy” line while other tasks to the same destination are sendingdocuments.

The grouping process can be implemented as follows: set the number ofpages or length of the transmission (to prevent unlimited send time onthe channel), identify and cache queued documents with the samedestination identifier, open connections on the transport, and send thedocuments with the same destination identifier over the open connection.

The group send feature may update its cache of queued documents withdocuments that enter the queue during transmission of a group, so longas the new documents share the same destination identifier.

Implementation of DocTrans in Various Embodiments:

In various embodiments, a framework for accepting a plug-in styleimplementation DLL for each transport type (or group of types) isprovided. Each DLL implements a predefined set of entry points thatenable support of various transport types.

Each entry point takes a resizable context structure that supports allinformation transferred between the DocTrans and the DLL. The documenttransports tolerate changes in the context structures' sizes, and eachdocument transport independently supports operations such as store &forward, task scheduling, sender or recipient intervention, least-costrouting rules, document or task lifespan, and deliver-or-delete optionswithout breaking the document task.

Configurable Queue Processor:

FIG. 7 is a block diagram illustrating an environment in which aconfigurable queue processor may operate in some embodiments. A documentserver 700 contains multiple components, including a configurable queueprocessor 702, server module 704, and a DocTrans module 706. Thedocument server can contain zero or more of any of these components. Theconfigurable queue processor 702 can allocate or deallocate documentflows, such as by invoking an application program interface (API)provided by the server module 704. The server module 704 may associateeach allocated document flow with a DocTrans module 706. The servermodule 704 may access a queue associated with the configurable queueprocessor. The queue can be stored in a database, such as a SQL server708 or in any other memory associated with the server and shared by theconfigurable queue processor and the document flows it allocates.

FIG. 8 is a block diagram illustrating operation of a configurable queueprocessor in some embodiments. A document 802 enters a document server804, such as a facsimile server, and is placed in a document queue 806.A configurable queue processor 807 can allocate or deallocate documentflows 808, such as based on the document server's resource utilization.Each document flow can be associated with one or more DocTrans modules810, such as modules 810 a and 810 b. The DocTrans modules receive thedocuments from the queue via the document flows. As an example, adocument flow can retrieve a document from the queue and provide theretrieved document to the associated DocTrans module for processing.DocTrans modules 810 a and 810 b may operate on different documentservers. A document in the queue may be assigned for processing to aparticular document flow based on the document's properties, such as itsmetadata or type. Example of properties that can be used in assigning adocument to a document flow include the document's size, author, type,protocol used to send the document, and so forth. A component may assigndocuments to a document flow. Alternatively, a document flow mayretrieve documents from the queue based on the document flow'sconfiguration, which can include an indication of these properties. Insome embodiments, the configurable queue processor can dynamicallyreconfigure document flow to handle documents with a different set ofmetadata or properties.

FIG. 9 is a flow diagram illustrating a process_document routine invokedby a document flow in some embodiments. The process_document routinestarts at block 902 where it receives an indication of a document.

At block 904, the routine retrieves the document. In variousembodiments, the routine may actively check a queue for pendingdocuments and retrieve documents the document flow associated with theroutine is configured to handle. Logic to check the queue is notillustrated. In various embodiments, the routine receives an indicationof the document, such as from a queue handling component.

At block 906, the routine provides the retrieved document to a DocTransmodule associated with the document flow component that invokes theroutine. As an example, the routine may invoke an application programinterface (“API”) provided by the associated DocTrans module to providethe document.

At block 908, the routine invokes a send_document routine provided bythe DocTrans module's API to forward or otherwise handle the document.The send_document routine was described above in detail in relation toFIG. 2.

At block 910, the routine returns.

FIG. 10 is a flow diagram illustrating an allocate_document_flow routineinvoked by a configurable queue processor in some embodiments. Theconfigurable queue processor invokes the routine to allocate ordeallocate document flows. The routine begins at block 1002.

At block 1004, the routine evaluates resources, such as systemresources, associated with the document server at which the routine isinvoked or the server with which the configurable queue processor isassociated. Examples of resources include processor, memory, storage,network bandwidth, and so forth. The routine may also evaluate thelength of the queue of pending documents.

At block 1006, the routine determines whether there is an efficientallocation of document flows. The routine can make this determination byevaluating the queue, system resources, document flows, and so forth. Asan example, the routine can evaluate the number and type of pendingdocuments in the queue and processor load to determine whether there isan efficient allocation of document flows. If documents are flowingthrough the system within some defined threshold period of time, theroutine may determine that the document flows are efficiently allocated.In such a case, the routine continues at block 1010, where it returns.Otherwise, the routine continues at block 1008.

At block 1008, the routine increases or decreases the number of documentflows, such as by allocating additional document flows or deallocatingdocument flows.

At block 1010, the routine returns.

FIG. 11 is a flow diagram illustrating a prevent_routing routine invokedby the configurable document server in some embodiments. The routinebegins at block 1102.

At decision block 1104, the routine determines whether an errorcondition exists. An error condition can exist when a document could notbe converted from one format to another, when a facsimile transmissionerror occurs, or another error condition occurs relating to theconfigurable document server. The error detection can be made by afacsimile board connected to the document server when a facsimiledocument is received, facsimile software, such as server facsimilesoftware, or other hardware or software component. If an error conditionexists, the routine continues at decision block 1106. Otherwise, theroutine returns at block 1114.

At decision block 1106, the routine determines whether a configurationoption is set to prevent routing when an error condition exists. If thatis the case, the routine continues at block 1108. Otherwise, the routinecontinues at block 1112.

At block 1108, the routine reports an error. As examples, the routinecan report errors to an administrator, a sender of the document, a userattempting to convert the document, and so forth. When the routinereports an error, the configurable document server may, in addition topreventing the document from being routed or forwarded to the intendedrecipient, take various workflow-related actions, such as notifyingusers or workflow processes, suspend workflow, and so forth. The routinemay also take queue-related actions, such as archiving workflow tasksuntil a notified user takes an action, the workflow task expires, and soforth.

At block 1110, the routine may route the document to an administratorfor further analysis and troubleshooting. The routine then returns atblock 1114.

At block 1112, the routine routes the document to the intended recipientbecause no error was detected. The routine then returns at block 1114.

CONCLUSION

Unless the context clearly requires otherwise, throughout thedescription and the claims, the words “comprise,” “comprising,” and thelike are to be construed in an inclusive sense, as opposed to anexclusive or exhaustive sense; that is to say, in the sense of“including, but not limited to.” As used herein, the terms “connected,”“coupled,” or any variant thereof, means any connection or coupling,either direct or indirect, between two or more elements; the coupling ofconnection between the elements can be physical, logical, or acombination thereof. Additionally, the words “herein,” “above,” “below,”and words of similar import, when used in this application, shall referto this application as a whole and not to any particular portions ofthis application. Where the context permits, words in the above DetailedDescription using the singular or plural number may also include theplural or singular number respectively. The word “or,” in reference to alist of two or more items, covers all of the following interpretationsof the word: any of the items in the list, all of the items in the list,and any combination of the items in the list. Although the terms“dialing rules” or “routing rules” may be used together or individually,the terms can refer to either or both types of rules.

The above detailed description of embodiments of the invention is notintended to be exhaustive or to limit the invention to the precise formdisclosed above. While specific embodiments of, and examples for, theinvention are described above for illustrative purposes, variousequivalent modifications are possible within the scope of the invention,as those skilled in the relevant art will recognize. For example, whileprocesses or blocks are presented in a given order, alternativeembodiments may perform routines having steps, or employ systems havingblocks, in a different order, and some processes or blocks may bedeleted, moved, added, subdivided, combined, and/or modified to providealternative or subcombinations. Each of these processes or blocks may beimplemented in a variety of different ways. Also, while processes orblocks are at times shown as being performed in series, these processesor blocks may instead be performed in parallel, or may be performed atdifferent times.

The teachings of the invention provided herein can be applied to othersystems, not necessarily the system described above. The elements andacts of the various embodiments described above can be combined toprovide further embodiments.

Any patents and applications and other references noted above, includingany that may be listed in accompanying filing papers, are incorporatedherein by reference. Aspects of the invention can be modified, ifnecessary, to employ the systems, functions, and concepts of the variousreferences described above to provide yet further embodiments of theinvention.

These and other changes can be made to the invention in light of theabove Detailed Description. While the above description describescertain embodiments of the invention, and describes the best modecontemplated, no matter how detailed the above appears in text, theinvention can be practiced in many ways. Details of the documenttransport layer may vary considerably in its implementation details,while still being encompassed by the invention disclosed herein. Asnoted above, particular terminology used when describing certainfeatures or aspects of the invention should not be taken to imply thatthe terminology is being redefined herein to be restricted to anyspecific characteristics, features, or aspects of the invention withwhich that terminology is associated. In general, the terms used in thefollowing claims should not be construed to limit the invention to thespecific embodiments disclosed in the specification, unless the aboveDetailed Description section explicitly defines such terms. Accordingly,the actual scope of the invention encompasses not only the disclosedembodiments, but also all equivalent ways of practicing or implementingthe invention under the claims.

While certain aspects of the invention are presented below in certainclaim forms, the inventors contemplate the various aspects of theinvention in any number of claim forms. For example, while only oneaspect of the invention is recited as embodied in a computer-readablemedium, other aspects may likewise be embodied in a computer-readablemedium. Accordingly, the inventors reserve the right to add additionalclaims after filing the application to pursue such additional claimforms for other aspects of the invention.

1. A method performed by a computer system for routing documents,comprising: receiving a configuration specification indicating how tohandle documents with errors; receiving a document at a document server;determining whether the received document is associated with an error;when the received document is associated with an error, preventingrouting of the received document; and when the received document is notassociated with an error, identifying an intended recipient and routingthe received document to the identified recipient.
 2. The method ofclaim 1 wherein the configuration specification is a configurationoption that is set by an administrator of the document server toindicate whether documents with errors should be routed to intendedrecipients.
 3. The method of claim 2 wherein the received document is afacsimile document.
 4. The method of claim 2 wherein the receiveddocument is a facsimile document and the determining includesdetermining whether a transmission error occurred when receiving thedocument.
 5. The method of claim 1 further comprising causing a workflowengine to suspend a workflow task when the received document isassociated with an error.
 6. The method of claim 1 wherein the receiveddocument is associated with an error when it cannot be converted fromone format to another.
 7. The method of claim 1 wherein the receiveddocument is associated with an error when it cannot be converted from anSMS message to a facsimile document.
 8. The method of claim 1 furthercomprising causing a workflow engine to change a workflow task when thereceived document is associated with an error wherein the changeincludes notifying a user other than the identified recipient.